SINGLE SIGN-ON AUTHENTICATION SYSTEM 



Cross Reference to Related Applications 

This application claims the benefit of United States Provisional Application Serial 
5 No. 60/500,391, filed by Rao et al. on September 5, 2003 and entitled "Single Sign-On 
Authentication System", which is incorporated herein by reference. 



Field of the Invention 

The present invention relates generally to computer network security, and, more 
10 particularly, to a system and a method for enabling a secure single sign-on to a computer 
network. 



Background of the Invention 

Currently, many companies employ computer networks that require users to 
15 separately sign-on to individual systems. For instance, a user may be required to sign-on 
to one computer system in order to access a spreadsheet application and then to another 
to access an e-mail application. Very often, users are prompted for a different user id and 
password during each sign on. The user must then remember several different user id's 
and passwords. 

20 In an attempt to deal with this problem, some vendors offer single sign-on (SSO) 

capability. However, conventional SSO systems typically entail complex authentication 
schemes. For example, U.S. Patent No. 5,684,950 to Dare et al., entitled "Method and 
System for Authenticating Users to Multiple Computer Servers Via a Single Sign-On," 
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discloses a method for authenticating a user to multiple computer servers. The method 
involves an authentication broker which receives an authentication request. The 
authentication broker then validates the request and issues a token. Once the user's 
workstation has received the token from the authentication broker, it then sends the token 
5 to the server that it wishes to interact with, to indicate that it has been authenticated. 
Although useful, SSO schemes such as the one described above involve 
a significant amount of overhead. Accordingly, improved SSO systems and methods are 
needed. 



10 Summary of the Invention 

The present invention provides a technique for enabling a secure, single sign-on 
to a computer network that requires comparatively less complexity and overhead than 
conventional single sign-on methods. 

A single sign-on authentication system includes an authentication component that 
15 determines whether a user is authenticated, and, if it is determined that the user is 
authenticated, generates a connection request, the connection request including an 
identifier and entitlement information. The system also includes an interface component 
that receives the connection request from the authentication component. The interface 
component compares the received identifier with an expected identifier. If they match, 
20 the interface component makes the entitlement information available to a server 
associated with the interface component. 

A method for enabling an authenticated user to connect to a server in a computer 
network includes receiving a connection request for an authenticated user, the connection 
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request including an identifier and entitlement information; comparing the received 
identifier with an expected identifier; and, if they match, making the entitlement 
information available to the server. 

These and other aspects, features and advantages of the present invention will 
5 become apparent from the following detailed description of preferred embodiments, 
which is to be read in connection with the accompanying drawings. 



Brief Description of the Drawings 

FIG. 1 is a block diagram showing an exemplary single sign-on authentication 
10 system; and 

FIG. 2 shows a flow diagram outlining an exemplary technique for processing a 
connection request. 



Description of Preferred Embodiments 

1 5 The present invention takes advantage of the notion that once a user has 

successfully signed on to a network, any computer system in the network receiving a 
connection request need only verify that the connection request was received from the 
network's sign-on component. If the connection request originated with the sign-on 
component, then there is no need to again query the user for authentication information 

20 and to authenticate the user. 

FIG. 1 is a block diagram of an exemplary single sign-on authentication system 
100. The single sign-on authentication system 100 includes a terminal 1 10, a sign-on 
component 120, and a server 150. The server 150 includes an interface component 152 
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and a request processor 154. While this system 100 includes a single terminal 1 10 and a 
single server 150, it is to be appreciated that typically there would be numerous other 
terminals and servers connected to the sign-on component 150. 

In operation, a user interacting with the terminal 1 10 is presented with a sign-on 
5 screen (not shown). The user then enters authentication information using this screen. 
The entered authentication information is then transmitted to the sign-on component 120. 
In general, authentication information includes any information used to verify a person's 
identity to ensure that the person has access to a particular computer network. 
Commonly, authentication information includes a unique identifier and a password. In an 
10 alternative embodiment, the terminal 1 10 includes a biometric device (e.g., fingerprint 
reader, retina scan) which may instead, or in addition, be used to verify the user's 
identity. 

Once the authentication information is received by the sign-on component 120, it 
can be used to determine whether the user is authorized to use the network. This can be 

15 done, for example, by comparing the received authentication information with 
information on file regarding valid users. 

After the user is authenticated, the sign-on component 120 preferably determines 
which systems in the network the user may access. The user might be prompted to select 
which of the systems to access. Alternatively, the selection process could be 

20 accomplished automatically (e.g., via a script). The sign-on component 120 also 
preferably determines the entitlement information needed by each of the individual 
systems that the user will access. In general, entitlement information includes 
information used by an individual computer system to assign system resources and/or 
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establish user preferences. The sign-on component 120 then issues several connection 

requests, each to connect to one of the selected systems. 

FIG. 2 is an exemplary flow diagram outlining an exemplary technique for 

processing a connection request. 
5 In step 202, header information from the connection request is obtained. This 

header information will generally include a source identifier and entitlement information. 

Assuming that the connection request is an HTTP request, the source identifier will 

include an Internet Protocol (IP) address. In general, an IP address is a 32-bit binary 

number that uniquely identifies a host (computer) connected to the Internet, for the 
10 purpose of communication through the transfer of packets. The use of IP addresses is 

part of the standard transmission control protocol/Internet protocol (TCP/IP). 

Next, in step 203, a determination is made as to whether the IP address is valid. 

Since the sign-on component 120 will have a known IP address, verification of the IP 

address can be accomplished by simply comparing the obtained IP address against the 
15 known IP address of the sign-on component 120. If the IP address cannot be verified 

(i.e., it doesn't match), control passes to step 204, where a message indicating an invalid 

connection is returned; otherwise, control passes to step 204. 

In step 204, a determination is made as to whether the entitlement information is 

in the correct format. If this information is not in the proper format (or isn't present), 
20 control passes to step 205, where a message indicating an invalid connection is returned; 

otherwise, control passes to step 206. (The format of the entitlement information will 

vary depending on the particular application. For example, if the information includes 

the user's e-mail address, the format could be xxxxx@xxxxx.com ). 
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In step 206, the request processor 154 is called. When the request processor 154 
is called, the entitlement information (e.g., e-mail address) can be used to establish access 
to the system. The request processor assigns resources and/or preferences using the 
entitlement information. Once access has been established, the user may thereupon 
5 directly connect to the server 150. The process terminates in step 207. 

It is be understood that the method outlined above an be implemented in various 
forms of hardware, software, firmware, special purpose processors, or a combination 
thereof. Preferably, the present invention is implemented in software as a program 
tangibly embodied on a program storage device. 
10 It is also to be understood that, because some of the constituent system 

components and method steps depicted in the accompanying figures are preferably 
implemented in software, the actual connections between the system components (or the 
process steps) may differ depending upon the manner in which the present invention is 
programmed. 

1 5 The invention will be further clarified by the following example: 



Example 1 



A user accesses a corporate intranet using a personal computer. The user's 
20 computer employs the Microsoft Windows operating system, and includes the Internet 
Explorer browser. The user must enter a unique identifier and a password to sign on. 

The user has access to a Lotus Notes e-mail system running on a Domino Server, 
securely maintained in the same facility as the sign-on system. The "interface 
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component" is a Domino System Application Program Interface (DSAPI) plug-in 
module. The DSAPI plug-in module is maintained on a DSAPI library. 

In operation, the user connects to the corporate intranet using the browser. The 
user then is queried for his user identifier and password. The user enters this information 
5 into the screen. The entered information is then transmitted to the sign-on component, 
where it is validated. The sign-on component then searches for systems that the user is 
entitled to access. It is determined that the user has access to the Lotus Notes e-mail 
system. The sign-on component then consults a cross-reference file, and finds the user's 
Lotus Notes e-mail address. The sign-on component calls the Domino Server. When the 

10 Domino Server is initially called, it invokes the DSAPI plug-in module. The module 
checks the IP address of the request packet to make sure that it matches the expected 
address. Assuming it matches, the module then formats a Common Name (CN) data 
structure with the e-mail address (and other information). The Domino Request 
Processor then uses the Domino-CN, to provide the user with appropriate access. 

15 Although illustrative embodiments of the present invention have been 

described herein with reference to the accompanying drawings, it is to be understood that 
the invention is not limited to those precise embodiments, and that various other changes 
and modifications may be affected therein by one skilled in the art without departing 
from the scope or spirit of the invention. 

20 
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